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REMARKS 

The final Office action mailed September 19, 2008, has been carefully reviewed and 
these remarks are responsive thereto. Claims 1-16 are pending and stand rejected. 

The Office action rejected claims 1-16 under 35 U.S.C. § 103 based on U.S. Patent 
7,143,435 (Droms et al, hereinafter "Droms"), U.S. Patent 5,884,024 (Lim et al., hereinafter 
"Lim") and U.S. Patent Application Pub. No. 2003/0005047 (Seki et al, hereinafter "Seki"). 
Applicants respectfully traverse. Even if a person of ordinary skill would have had reason to 
combine teachings of Droms, Lim and Seki, which Applicants do not concede, the combination 
would not teach all features of the independent claims. 

Claim 1 is directed to a method in which a DHCP relay is used to modify the protocol 
field in the DHCP messages so as to control the interaction between the DHCP server and the 
DHCP client. The Office action admits at page 3 that Droms and Lim fail to teach the following 
features of claim 1 : 

wherein modifying the one or more protocol fields includes: 

upon receiving a DHCP message for request sent from the DHCP client to 
the DHCP server, filling in at least one field associated with the DHCP relay in 
the DHCP message for request, and 

upon receiving a DHCP message for response sent from the DHCP server 
to the DHCP client, replacing at least one server parameter of a field associated 
with the DHCP server in the DHCP message for response with at least one relay 
parameter of the DHCP relay. 

The Office action then asserts that these features are taught by Seki. However, the 
teachings of Seki do not relate to DHCP messages. Instead, Seki describes a data transfer 
method using a caching technique and/or a compression technique to reduce network load 
between data transfer devices. A server side proxy 30 replaces the reply data of a reply message 
received from a server 20 with a corresponding "fingerprint" registered in a fingerprint cache 34, 
and transfers the resulting reply message to the client side proxy 40. The purpose of the 
technique described in Seki is to reduce network load by transferring a fingerprint instead of 
actual data; the fingerprint is replaced with the actual data at the client side proxy. No part of 
Seki suggests that the data replaced with a fingerprint is data within a DHCP message. Even if 
some part of a message in Droms or Lim was replaced with a fingerprint, there is nothing to 
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suggest (and the Office has not explained why) the replaced portion would be a server parameter 
field associated with a DHCP server. Accordingly, Seki fails to teach "upon receiving a DHCP 
message for request sent from the DHCP client to the DHCP server, filling in at least one field 
associated with the DHCP relay in the DHCP message for request" and similarly fails to teach 
"upon receiving a DHCP message for response sent from the DHCP server to the DHCP client, 
replacing at least one server parameter of a field associated with the DHCP server in the DHCP 
message for response with at least one relay parameter of the DHCP relay." 

Moreover, a person of ordinary skill would not have had reason to combine teachings of 
Droms and Lim with teachings from Seki. As justification for the combination, the Office action 
asserts that "it would have been obvious ... to modify or incorporate Seki's teachings of replacing 
data in messages from a server with Droms-Lim's [sic] to provide for a more efficient messaging 
system." The Office has not explained how such a combination would increase efficiency. For 
example, the Office has not explained how utilization of Seki's method of replacing data with a 
"fingerprint" at one server and then replacing the fingerprint with the actual data at another 
server will make communications more efficient. If anything, it would seem that combination of 
Seki with Droms would decrease efficiency. For example, Droms describes a DHCP relay 
sending a RADIUS authentication result of an original physical port access request of a DHCP 
client's host to a DHCP server for the authentication and address assignment process by means 
of DHCP information. The function of the DHCP relay is to carry the RADIUS authentication 
result message by forwarding the DHCP Message between the DHCP client and the DHCP 
server. It is not clear how replacing some portion of the forwarded DHCP Message with a 
"fingerprint" of the replaced portion would improve efficiency. 

For at least the above reasons, claim 1 is allowable. Claims 2-8 depend from claim 1 and 
are thus allowable for the same reasons as claim 1, and because of additional recited features. 
For example, claims 4 recites "wherein for a DHCPDISCOVER or DHCPREQUEST message 
sent from the DHCP client to the DHCP server, the DHCP relay fills in the at least one field 
associated with the DHCP relay with a value so that a DHCPOFFER, DHCPACK or DHCPNAK 
response from the DHCP server to the DHCP client can be sent to the DHCP relay." The Office 
action asserts at page 6 that Lim teaches this feature at Figures 5 and 6 and in the Abstract. In 
Lim, the DHCP relay embeds a trusted identifier in the DHCPREQUEST message and the 
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DHCP server controls the number of the IP addresses which could be allocated according to the 
trusted identifier. This is different from claim 4, which recites filling in a field value so as to 
cause certain specified messages to be sent to the DHCP relay. Lim does not indicate that the 
inclusion of a trusted identifier causes one of the message types recited by claim 4 to be sent to 
the DHCP relay. For example, it is not clear from Lim that omitting the trusted identifier would 
cause one of the specified messages to go somewhere other than a DHCP relay. 

Independent claim 9 recites a DHCP relay configured to perform operations similar to 
steps recited in claim 1, and is thus allowable for the same reasons as claim 1. Claims 10-13 
depend from claim 9 and are thus allowable for at least the same reasons as claim 9. 

Independent claim 14 recites features similar to those discussed above in connection with 
claim 1, and is thus allowable for the same reasons as claim 1. Claims 15 and 16 depend from 
claim 9 and are thus allowable for at least the same reasons as claim 9. 

All rejections having been fully addressed, Applicants respectfully submit that this 
application is in condition for immediate allowance and respectfully solicit prompt notification 
of the same. 

Respectfully submitted, 

BANNER & WITCOFF, LTD. 

Dated: December 19, 2008 By: /H. Wayne Porter/ 

H. Wayne Porter 
Reg. No. 42,084 

1100 13th Street, N.W., Suite 1200 
Washington, D.C. 20005-4051 
Tel: (202) 824-3000 
Fax: (202) 824-3001 
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